Add select clause for specific user fields

server/routes/users/@me.ts

Convert iterative upserts to transactional batch operations

server/routes/users/[id]/bookmarks.ts

Replace randomUUID with uuidv7 generation

server/routes/users/[id]/group-order.ts

Add missing cascade deletes for user data cleanup

server/routes/users/[id]/index.ts

Add UUID generation and transactional list creation with validation

server/routes/users/[id]/lists/index.post.ts

Add relationLoadStrategy and UUID generation for list items

server/routes/users/[id]/lists/index.patch.ts

Convert find+create/update to upsert with transactional batches

server/routes/users/[id]/progress.ts

Replace conditional writes with direct upsert operations

server/routes/users/[id]/progress/[tmdb_id]/index.ts

Convert iterative upserts to transactional batch with error handling

server/routes/users/[id]/progress/import.ts

Add select clause to narrow session query results

server/routes/users/[id]/sessions.ts

Remove redundant queries and use update return value directly

server/routes/sessions/[sid]/index.ts

Add select clause to narrow user existence check

server/routes/users/[id]/settings.ts

Add select clause and narrow query results for watch history

server/routes/users/[id]/watch-history.ts

Convert iterative upserts to transactional batch operations

server/routes/users/[id]/watch-history/[tmdbid]/index.ts

Replace randomUUID with uuidv7 and implement session upsert

server/utils/auth.ts

Replace randomUUID with uuidv7 for challenge code generation

server/utils/challenge.ts

Simplify type annotation for player status store

server/utils/playerStatus.ts

Add database indexes and unique constraints for query optimization

prisma/schema.prisma

Create hash indexes and unique constraints for performance

prisma/migrations/20260301145729_add_unique_constraints/migration.sql

Add uuidv7, pg, and related dependencies for optimizations

package.json

Document new DB_POOL_MAX environment variable

.env.example

...

server/routes/lists/[id].get.ts

Description

The watch-history PUT handler catches all errors (including Zod validation failures) and always
returns a 500. This breaks API semantics and makes client-side input errors look like server
failures.

Code

server/routes/users/[id]/watch-history/[tmdbid]/index.ts[R58-69]

// Accept single object (normal playback) or array (e.g. user import)
const bodySchema = z.union([
  watchHistoryItemSchema,
-        z.array(watchHistoryItemSchema),
+        z.array(watchHistoryItemSchema).max(1000),
]);
const parsed = bodySchema.parse(body);
const items = Array.isArray(parsed) ? parsed : [parsed];
-      const results = [];
-
-      for (const validatedBody of items) {
+      const upsertPromises = items.map(validatedBody => {
  const itemTmdbId = items.length === 1 ? tmdbId : (validatedBody.tmdbId ?? tmdbId);
  const watchedAt = defaultAndCoerceDateTime(validatedBody.watchedAt);
  const now = new Date();

Evidence

The Zod parse() call is inside the same try/catch as DB logic; any parse failure will land in the
catch and be turned into a 500 response.

server/routes/users/[id]/watch-history/[tmdbid]/index.ts[54-135]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The watch-history PUT endpoint wraps request validation and DB writes in one broad try/catch and always throws a 500 on error. This turns invalid input into 500 responses.
### Issue Context
Zod `parse()` throws on invalid input; those should be 4xx errors.
### Fix Focus Areas
- server/routes/users/[id]/watch-history/[tmdbid]/index.ts[54-135]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Watch-history writes now use a '\n' sentinel for movie season_id/episode_id and upsert on that
composite key; existing rows stored with NULLs (allowed by schema) will not match and can result in
duplicate movie rows. This risks data bloat and inconsistent reads/cleanup behavior over time.

Code

server/routes/users/[id]/watch-history/[tmdbid]/index.ts[R72-77]

const normSeasonId = validatedBody.meta.type === 'movie' ? '\n' : validatedBody.seasonId ?? null;
const normEpisodeId = validatedBody.meta.type === 'movie' ? '\n' : validatedBody.episodeId ?? null;
-        const existingItem = await prisma.watch_history.findUnique({
-          where: {
-            tmdb_id_user_id_season_id_episode_id: {
-              tmdb_id: itemTmdbId,
-              user_id: userId,
-              season_id: normSeasonId,
-              episode_id: normEpisodeId,
-            },
-          },
-        });
-
const data = {
  duration: parseFloat(validatedBody.duration),
  watched: parseFloat(validatedBody.watched),

Evidence

The schema allows watch_history.season_id and episode_id to be NULL while also being part of a
UNIQUE constraint. The PR’s own progress_items migration documents that NULLs don’t behave as equal
under UNIQUE constraints, motivating the sentinel approach—so if watch_history already contains NULL
movie rows, an upsert keyed on '\n' will not update them.

prisma/schema.prisma[152-168]
server/routes/users/[id]/watch-history/[tmdbid]/index.ts[71-105]
prisma/migrations/20260301172358_normalize_progress_movie_sentinels/migration.sql[1-4]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`watch_history` upserts for movies now use `season_id='\n'` and `episode_id='\n'`. If existing movie rows are stored with NULLs (schema allows NULL), the upsert keyed on `'\n'` will not match and will create a second row.
## Issue Context
- `watch_history.season_id` and `episode_id` are nullable but part of a composite UNIQUE.
- The PR already needed a progress_items migration to normalize NULL→'\n' because UNIQUE treats NULLs as distinct.
## Fix Focus Areas
- server/routes/users/[id]/watch-history/[tmdbid]/index.ts[71-105]
- prisma/schema.prisma[152-168]
- prisma/migrations/20260301172358_normalize_progress_movie_sentinels/migration.sql[1-23]
## Suggested change
- Add a new SQL migration for `watch_history` similar to the progress_items normalization:
- Delete duplicates where one row has NULLs and another has `'\n'` for the same `(tmdb_id,user_id)`.
- Update remaining NULL `season_id`/`episode_id` to `'\n'`.
- Ensure any other `watch_history` writers also normalize consistently (movies always store `'\n'` for both IDs).
- Consider whether `'\n'` is the best sentinel vs a more explicit value (but keep consistent across reads/writes).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Switching movie season_id/episode_id to the '\n' sentinel without normalizing existing NULL rows can
cause progress import to fail: it reuses an existing row’s primary key (id) but changes the
composite unique key used for upsert lookups, causing Prisma to attempt a create that collides on
the primary key.

Code

server/routes/users/[id]/progress.ts[R260-287]

+      const progressItem = await prisma.progress_items.upsert({
where: {
tmdb_id_user_id_season_id_episode_id: {
  tmdb_id: tmdbId,
  user_id: userId,
-            season_id: validatedBody.seasonId || null,
-            episode_id: validatedBody.episodeId || null,
+            season_id: validatedBody.meta.type === 'movie' ? '\n' : validatedBody.seasonId || null,
+            episode_id: validatedBody.meta.type === 'movie' ? '\n' : validatedBody.episodeId || null,
},
},
+        update: {
+          duration: BigInt(validatedBody.duration),
+          watched: BigInt(validatedBody.watched),
+          meta: validatedBody.meta,
+          updated_at: now,
+        },
+        create: {
+          id: uuidv7(),
+          tmdb_id: tmdbId,
+          user_id: userId,
+          season_id: validatedBody.meta.type === 'movie' ? '\n' : validatedBody.seasonId || null,
+          episode_id: validatedBody.meta.type === 'movie' ? '\n' : validatedBody.episodeId || null,
+          season_number: validatedBody.seasonNumber || null,
+          episode_number: validatedBody.episodeNumber || null,
+          duration: BigInt(validatedBody.duration),
+          watched: BigInt(validatedBody.watched),
+          meta: validatedBody.meta,
+          updated_at: now,
+        },

Evidence

The schema allows NULL season_id/episode_id but the new write path uses '\n' for movies. In the
import route, existing rows are re-upserted by the composite unique key
(tmdb_id,user_id,season_id,episode_id) while also reusing the existing row’s id. If an existing
movie row stored NULLs, rewriting the season/episode ids to '\n' makes the upsert lookup miss, so
Prisma will try to create a new row using id: existingItem.id and fail due to duplicate primary
key.

prisma/schema.prisma[64-79]
server/routes/users/[id]/progress.ts[260-287]
server/routes/users/[id]/progress/import.ts[85-154]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Progress import can fail because it rewrites movie rows to use the '\n' sentinel but still upserts by the composite unique key while reusing `existingItem.id`. If the existing DB row has NULL season/episode ids, the composite lookup misses and Prisma attempts `create` with an already-taken primary key.
### Issue Context
- `season_id`/`episode_id` are nullable in Prisma schema.
- New code uses '\n' as a sentinel for movies.
- Import path reuses existing `id` while potentially changing season/episode ids.
### Fix Focus Areas
- server/routes/users/[id]/progress/import.ts[85-154]
- server/routes/users/[id]/progress.ts[260-287]
- prisma/schema.prisma[64-79]
### Suggested fixes (pick one)
1) **Data migration (recommended)**
- Add a SQL migration that updates existing movie rows to set `season_id='\n'` and `episode_id='\n'` where they are NULL.
- Do similarly for `watch_history` if using the same sentinel.
- Ensure your JSON `meta` has a reliable discriminator to identify movies.
2) **Code fix in import**
- For updates to existing rows, run `update({ where: { id: existingItem.id }, data: { ... , season_id: '\n', episode_id: '\n' } })` instead of upsert-by-composite.
- Only use composite upsert for brand-new rows (fresh ids).
3) **Alternative schema strategy**
- Avoid sentinels by restructuring uniqueness (e.g., separate movie vs episode uniqueness), but that’s a larger refactor.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Different endpoints write movie progress_items with episode_id/season_id as either NULL or "\n";
with the new upsert in /progress this can create parallel rows for the same movie and also makes
cleanup misclassify movie rows stored with "\n" as episodes.

Code

server/routes/users/[id]/progress.ts[R260-263]

+      const progressItem = await prisma.progress_items.upsert({
where: {
tmdb_id_user_id_season_id_episode_id: {
tmdb_id: tmdbId,

Evidence

The progress cleanup logic treats “movie rows” as those with a falsy episode_id (NULL), but other
endpoints explicitly normalize movies to use the "\n" sentinel (truthy). The updated /progress
upsert uses NULL for missing IDs, so it will not match/update rows created via the sentinel approach
and may create a second row under a different compound key.

server/routes/users/[id]/progress.ts[162-165]
server/routes/users/[id]/progress.ts[260-288]
server/routes/users/[id]/progress/import.ts[117-126]
server/routes/users/[id]/progress/[tmdb_id]/index.ts[32-35]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`progress_items` movie rows are represented inconsistently across endpoints (`NULL` vs `"\n"` for season_id/episode_id). With the new `upsert()` in `/users/[id]/progress.ts`, this can lead to parallel rows for the same logical movie progress record and also causes the cleanup routine to misclassify movie rows stored with `"\n"` as episodes.
### Issue Context
Other progress endpoints already normalize movies to use `"\n"` (and formats convert it back to null/undefined), but `/users/[id]/progress.ts` still writes `NULL`. Cleanup logic assumes movies have a falsy `episode_id`.
### Fix Focus Areas
- server/routes/users/[id]/progress.ts[162-165]
- server/routes/users/[id]/progress.ts[260-288]
- server/routes/users/[id]/progress/import.ts[117-126]
- server/routes/users/[id]/progress/[tmdb_id]/index.ts[32-35]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

With the newly-added unique constraint on lists(user_id,name), renaming a list to an existing name
for that user will raise Prisma P2002, but the PATCH endpoint doesn’t translate it to a 409 (unlike
the POST endpoint). This will surface as a 500 error to clients.

Code

server/routes/users/[id]/lists/index.patch.ts[R64-69]

description:
validatedBody.description !== undefined ? validatedBody.description : list.description,
public: validatedBody.public ?? list.public,
+          updated_at: new Date(),
},
});

Evidence

The schema now enforces uniqueness on (user_id, name). The PATCH route updates name but has no
error handling for unique violations, while the POST route explicitly catches P2002 and returns
409—indicating intended API behavior.

prisma/schema.prisma[44-56]
server/routes/users/[id]/lists/index.patch.ts[54-69]
server/routes/users/[id]/lists/index.post.ts[89-95]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
PATCH /users/[id]/lists can now violate the new unique constraint on (user_id, name) and return an unhandled Prisma P2002 (500) instead of a 409.
### Issue Context
POST already implements both an app-level guard and a P2002 catch to produce a clean 409.
### Fix Focus Areas
- server/routes/users/[id]/lists/index.patch.ts[54-69]
- prisma/schema.prisma[44-56]
### Suggested approach
- Wrap the `$transaction` in a try/catch and map `err.code === 'P2002'` to `createError({statusCode:409,...})`.
- Optionally add an app-level check similar to POST when `validatedBody.name` is provided (check for another list with same name for the user, excluding the current list id).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

makeSession() uses sessions_user_device_unique as the compound-unique selector, but this appears
inconsistent with how Prisma generates compound selectors (field-name based). This is likely to fail
at compile-time or at runtime when login calls sessions.upsert().

Code

server/utils/auth.ts[R43-47]

+    // Atomic upsert — backed by @@unique([user, device]) in schema
+    return await prisma.sessions.upsert({
+      where: {
+        sessions_user_device_unique: { user, device },
+      },

Evidence

In your schema, the sessions uniqueness is declared with map: "sessions_user_device_unique", but
across the codebase compound-unique selectors are referenced by the concatenated field names (not
the map value). For example, bookmarks uses tmdb_id_user_id in code even though the constraint
is mapped to bookmarks_tmdb_id_user_id_unique, strongly suggesting sessions should use something
like user_device rather than sessions_user_device_unique.

server/utils/auth.ts[37-65]
prisma/schema.prisma[81-92]
prisma/schema.prisma[12-23]
server/routes/users/[id]/bookmarks/[tmdbid]/index.ts[40-43]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`prisma.sessions.upsert()` is using `sessions_user_device_unique` as the compound-unique selector key. Prisma client compound unique selector keys are typically generated from field names (and `map:` only affects the DB constraint name), so this is likely an invalid selector and will break login.
## Issue Context
- `sessions` has `@@unique([user, device], map: "sessions_user_device_unique")`.
- Other code (e.g. bookmarks) uses field-based selector keys like `tmdb_id_user_id` despite the constraint being mapped to a different DB name.
## Fix Focus Areas
- server/utils/auth.ts[43-64]
- prisma/schema.prisma[81-92]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

makeSession() uses sessions_user_device_unique as the compound-unique selector, but this appears
inconsistent with how Prisma generates compound selectors (field-name based). This is likely to fail
at compile-time or at runtime when login calls sessions.upsert().

Code

server/utils/auth.ts[R43-47]

+    // Atomic upsert — backed by @@unique([user, device]) in schema
+    return await prisma.sessions.upsert({
+      where: {
+        sessions_user_device_unique: { user, device },
+      },

Evidence

In your schema, the sessions uniqueness is declared with map: "sessions_user_device_unique", but
across the codebase compound-unique selectors are referenced by the concatenated field names (not
the map value). For example, bookmarks uses tmdb_id_user_id in code even though the constraint
is mapped to bookmarks_tmdb_id_user_id_unique, strongly suggesting sessions should use something
like user_device rather than sessions_user_device_unique.

server/utils/auth.ts[37-65]
prisma/schema.prisma[81-92]
prisma/schema.prisma[12-23]
server/routes/users/[id]/bookmarks/[tmdbid]/index.ts[40-43]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`prisma.sessions.upsert()` is using `sessions_user_device_unique` as the compound-unique selector key. Prisma client compound unique selector keys are typically generated from field names (and `map:` only affects the DB constraint name), so this is likely an invalid selector and will break login.
## Issue Context
- `sessions` has `@@unique([user, device], map: "sessions_user_device_unique")`.
- Other code (e.g. bookmarks) uses field-based selector keys like `tmdb_id_user_id` despite the constraint being mapped to a different DB name.
## Fix Focus Areas
- server/utils/auth.ts[43-64]
- prisma/schema.prisma[81-92]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

makeSession() uses sessions_user_device_unique as the compound-unique selector, but this appears
inconsistent with how Prisma generates compound selectors (field-name based). This is likely to fail
at compile-time or at runtime when login calls sessions.upsert().

Code

server/utils/auth.ts[R43-47]

+    // Atomic upsert — backed by @@unique([user, device]) in schema
+    return await prisma.sessions.upsert({
+      where: {
+        sessions_user_device_unique: { user, device },
+      },

Evidence

In your schema, the sessions uniqueness is declared with map: "sessions_user_device_unique", but
across the codebase compound-unique selectors are referenced by the concatenated field names (not
the map value). For example, bookmarks uses tmdb_id_user_id in code even though the constraint
is mapped to bookmarks_tmdb_id_user_id_unique, strongly suggesting sessions should use something
like user_device rather than sessions_user_device_unique.

server/utils/auth.ts[37-65]
prisma/schema.prisma[81-92]
prisma/schema.prisma[12-23]
server/routes/users/[id]/bookmarks/[tmdbid]/index.ts[40-43]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`prisma.sessions.upsert()` is using `sessions_user_device_unique` as the compound-unique selector key. Prisma client compound unique selector keys are typically generated from field names (and `map:` only affects the DB constraint name), so this is likely an invalid selector and will break login.
## Issue Context
- `sessions` has `@@unique([user, device], map: "sessions_user_device_unique")`.
- Other code (e.g. bookmarks) uses field-based selector keys like `tmdb_id_user_id` despite the constraint being mapped to a different DB name.
## Fix Focus Areas
- server/utils/auth.ts[43-64]
- prisma/schema.prisma[81-92]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

makeSession() uses sessions_user_device_unique as the compound-unique selector, but this appears
inconsistent with how Prisma generates compound selectors (field-name based). This is likely to fail
at compile-time or at runtime when login calls sessions.upsert().

Code

server/utils/auth.ts[R43-47]

+    // Atomic upsert — backed by @@unique([user, device]) in schema
+    return await prisma.sessions.upsert({
+      where: {
+        sessions_user_device_unique: { user, device },
+      },

Evidence

In your schema, the sessions uniqueness is declared with map: "sessions_user_device_unique", but
across the codebase compound-unique selectors are referenced by the concatenated field names (not
the map value). For example, bookmarks uses tmdb_id_user_id in code even though the constraint
is mapped to bookmarks_tmdb_id_user_id_unique, strongly suggesting sessions should use something
like user_device rather than sessions_user_device_unique.

server/utils/auth.ts[37-65]
prisma/schema.prisma[81-92]
prisma/schema.prisma[12-23]
server/routes/users/[id]/bookmarks/[tmdbid]/index.ts[40-43]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`prisma.sessions.upsert()` is using `sessions_user_device_unique` as the compound-unique selector key. Prisma client compound unique selector keys are typically generated from field names (and `map:` only affects the DB constraint name), so this is likely an invalid selector and will break login.
## Issue Context
- `sessions` has `@@unique([user, device], map: "sessions_user_device_unique")`.
- Other code (e.g. bookmarks) uses field-based selector keys like `tmdb_id_user_id` despite the constraint being mapped to a different DB name.
## Fix Focus Areas
- server/utils/auth.ts[43-64]
- prisma/schema.prisma[81-92]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The pg Pool is configured with a default max of 100000 connections when DB_POOL_MAX is not set.
This can exhaust DB resources and destabilize the app under load or even at startup.

Code

server/utils/prisma.ts[R5-10]

+const pool = new Pool({
connectionString: process.env.DATABASE_URL,
+  max: parseInt(process.env.DB_POOL_MAX || '100000', 10),
+  connectionTimeoutMillis: 10000,
+  idleTimeoutMillis: 300000,
});

Evidence

server/utils/prisma.ts hardcodes a very large default pool size and .env.example documents it as
the default. This is a high-risk default because it applies whenever DB_POOL_MAX is absent.

server/utils/prisma.ts[1-10]
.env.example[25-26]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The current default Postgres connection pool max is set to 100000 when `DB_POOL_MAX` is unset. This default is unsafe and can overwhelm typical Postgres configurations.
## Issue Context
`max` is derived from `parseInt(process.env.DB_POOL_MAX || '100000', 10)`. This means self-hosters who do nothing will still get a 100000 max.
## Fix Focus Areas
- server/utils/prisma.ts[1-10]
- .env.example[25-26]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The pg Pool is configured with a default max of 100000 connections when DB_POOL_MAX is not set.
This can exhaust DB resources and destabilize the app under load or even at startup.

Code

server/utils/prisma.ts[R5-10]

+const pool = new Pool({
connectionString: process.env.DATABASE_URL,
+  max: parseInt(process.env.DB_POOL_MAX || '100000', 10),
+  connectionTimeoutMillis: 10000,
+  idleTimeoutMillis: 300000,
});

Evidence

server/utils/prisma.ts hardcodes a very large default pool size and .env.example documents it as
the default. This is a high-risk default because it applies whenever DB_POOL_MAX is absent.

server/utils/prisma.ts[1-10]
.env.example[25-26]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The current default Postgres connection pool max is set to 100000 when `DB_POOL_MAX` is unset. This default is unsafe and can overwhelm typical Postgres configurations.
## Issue Context
`max` is derived from `parseInt(process.env.DB_POOL_MAX || '100000', 10)`. This means self-hosters who do nothing will still get a 100000 max.
## Fix Focus Areas
- server/utils/prisma.ts[1-10]
- .env.example[25-26]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The pg Pool is configured with a default max of 100000 connections when DB_POOL_MAX is not set.
This can exhaust DB resources and destabilize the app under load or even at startup.

Code

server/utils/prisma.ts[R5-10]

+const pool = new Pool({
connectionString: process.env.DATABASE_URL,
+  max: parseInt(process.env.DB_POOL_MAX || '100000', 10),
+  connectionTimeoutMillis: 10000,
+  idleTimeoutMillis: 300000,
});

Evidence

server/utils/prisma.ts hardcodes a very large default pool size and .env.example documents it as
the default. This is a high-risk default because it applies whenever DB_POOL_MAX is absent.

server/utils/prisma.ts[1-10]
.env.example[25-26]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The current default Postgres connection pool max is set to 100000 when `DB_POOL_MAX` is unset. This default is unsafe and can overwhelm typical Postgres configurations.
## Issue Context
`max` is derived from `parseInt(process.env.DB_POOL_MAX || '100000', 10)`. This means self-hosters who do nothing will still get a 100000 max.
## Fix Focus Areas
- server/utils/prisma.ts[1-10]
- .env.example[25-26]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The pg Pool is configured with a default max of 100000 connections when DB_POOL_MAX is not set.
This can exhaust DB resources and destabilize the app under load or even at startup.

Code

server/utils/prisma.ts[R5-10]

+const pool = new Pool({
connectionString: process.env.DATABASE_URL,
+  max: parseInt(process.env.DB_POOL_MAX || '100000', 10),
+  connectionTimeoutMillis: 10000,
+  idleTimeoutMillis: 300000,
});

Evidence

server/utils/prisma.ts hardcodes a very large default pool size and .env.example documents it as
the default. This is a high-risk default because it applies whenever DB_POOL_MAX is absent.

server/utils/prisma.ts[1-10]
.env.example[25-26]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The current default Postgres connection pool max is set to 100000 when `DB_POOL_MAX` is unset. This default is unsafe and can overwhelm typical Postgres configurations.
## Issue Context
`max` is derived from `parseInt(process.env.DB_POOL_MAX || '100000', 10)`. This means self-hosters who do nothing will still get a 100000 max.
## Fix Focus Areas
- server/utils/prisma.ts[1-10]
- .env.example[25-26]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new migration adds unique indexes on lists(user_id,name) and sessions(user,device) and will
fail if the database already contains duplicates. This can block deploys/startup unless you
pre-deduplicate data.

Code

prisma/migrations/20260301145729_add_unique_constraints/migration.sql[R4-22]

+  - A unique constraint covering the columns `[user_id,name]` on the table `lists` will be added. If there are existing duplicate values, this will fail.
+  - A unique constraint covering the columns `[user,device]` on the table `sessions` will be added. If there are existing duplicate values, this will fail.
+
+*/
+-- CreateIndex
+CREATE INDEX "bookmarks_user_id_idx" ON "bookmarks" USING HASH ("user_id");
+
+-- CreateIndex
+CREATE UNIQUE INDEX "lists_user_id_name_unique" ON "lists"("user_id", "name");
+
+-- CreateIndex
+CREATE INDEX "progress_items_user_id_idx" ON "progress_items" USING HASH ("user_id");
+
+-- CreateIndex
+CREATE INDEX "sessions_user_idx" ON "sessions" USING HASH ("user");
+
+-- CreateIndex
+CREATE UNIQUE INDEX "sessions_user_device_unique" ON "sessions"("user", "device");
+

Evidence

The migration explicitly warns about duplicates causing failure and proceeds to create the unique
indexes. Without a prior data cleanup step, running this migration against an existing DB may be a
deployment blocker.

prisma/migrations/20260301145729_add_unique_constraints/migration.sql[1-6]
prisma/migrations/20260301145729_add_unique_constraints/migration.sql[11-22]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Migration introduces new unique constraints that will fail if duplicates already exist, potentially blocking deployment.
## Issue Context
The migration itself warns about failure on duplicates.
## Fix Focus Areas
- prisma/migrations/20260301145729_add_unique_constraints/migration.sql[1-24]
- prisma/schema.prisma[44-56]
- prisma/schema.prisma[81-92]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new migration adds unique indexes on lists(user_id,name) and sessions(user,device) and will
fail if the database already contains duplicates. This can block deploys/startup unless you
pre-deduplicate data.

Code

prisma/migrations/20260301145729_add_unique_constraints/migration.sql[R4-22]

+  - A unique constraint covering the columns `[user_id,name]` on the table `lists` will be added. If there are existing duplicate values, this will fail.
+  - A unique constraint covering the columns `[user,device]` on the table `sessions` will be added. If there are existing duplicate values, this will fail.
+
+*/
+-- CreateIndex
+CREATE INDEX "bookmarks_user_id_idx" ON "bookmarks" USING HASH ("user_id");
+
+-- CreateIndex
+CREATE UNIQUE INDEX "lists_user_id_name_unique" ON "lists"("user_id", "name");
+
+-- CreateIndex
+CREATE INDEX "progress_items_user_id_idx" ON "progress_items" USING HASH ("user_id");
+
+-- CreateIndex
+CREATE INDEX "sessions_user_idx" ON "sessions" USING HASH ("user");
+
+-- CreateIndex
+CREATE UNIQUE INDEX "sessions_user_device_unique" ON "sessions"("user", "device");
+

Evidence

The migration explicitly warns about duplicates causing failure and proceeds to create the unique
indexes. Without a prior data cleanup step, running this migration against an existing DB may be a
deployment blocker.

prisma/migrations/20260301145729_add_unique_constraints/migration.sql[1-6]
prisma/migrations/20260301145729_add_unique_constraints/migration.sql[11-22]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Migration introduces new unique constraints that will fail if duplicates already exist, potentially blocking deployment.
## Issue Context
The migration itself warns about failure on duplicates.
## Fix Focus Areas
- prisma/migrations/20260301145729_add_unique_constraints/migration.sql[1-24]
- prisma/schema.prisma[44-56]
- prisma/schema.prisma[81-92]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new migration adds unique indexes on lists(user_id,name) and sessions(user,device) and will
fail if the database already contains duplicates. This can block deploys/startup unless you
pre-deduplicate data.

Code

prisma/migrations/20260301145729_add_unique_constraints/migration.sql[R4-22]

+  - A unique constraint covering the columns `[user_id,name]` on the table `lists` will be added. If there are existing duplicate values, this will fail.
+  - A unique constraint covering the columns `[user,device]` on the table `sessions` will be added. If there are existing duplicate values, this will fail.
+
+*/
+-- CreateIndex
+CREATE INDEX "bookmarks_user_id_idx" ON "bookmarks" USING HASH ("user_id");
+
+-- CreateIndex
+CREATE UNIQUE INDEX "lists_user_id_name_unique" ON "lists"("user_id", "name");
+
+-- CreateIndex
+CREATE INDEX "progress_items_user_id_idx" ON "progress_items" USING HASH ("user_id");
+
+-- CreateIndex
+CREATE INDEX "sessions_user_idx" ON "sessions" USING HASH ("user");
+
+-- CreateIndex
+CREATE UNIQUE INDEX "sessions_user_device_unique" ON "sessions"("user", "device");
+

Evidence

The migration explicitly warns about duplicates causing failure and proceeds to create the unique
indexes. Without a prior data cleanup step, running this migration against an existing DB may be a
deployment blocker.

prisma/migrations/20260301145729_add_unique_constraints/migration.sql[1-6]
prisma/migrations/20260301145729_add_unique_constraints/migration.sql[11-22]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Migration introduces new unique constraints that will fail if duplicates already exist, potentially blocking deployment.
## Issue Context
The migration itself warns about failure on duplicates.
## Fix Focus Areas
- prisma/migrations/20260301145729_add_unique_constraints/migration.sql[1-24]
- prisma/schema.prisma[44-56]
- prisma/schema.prisma[81-92]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools